Page history of WSL 삽질기

윈도우 개발환경 삽질기를 거치면서 윈도우 네이티브 환경으로 개발 환경을 세팅했지만, 여전히 가끔 뭔가 윈도우라서 불편한 상황은 발생할 수 밖에 없었다. 그래서 WSL에 대한 끈을 놓지 않고 계속 이것저것 시도해보는 중이다. WSL을 윈도우에서 사용하는 방법은 크게 세 가지가 있다.

WSL은 커맨드라인으로만 사용하고 GUI 도구는 윈도우용을 사용

이 방법은 GUI 개발 도구를 거의 안 쓰는 사람들에게는 아무 문제 없는 완벽한 방법이다. 이를테면 Vimpire라든가, Vimpire라든가, Vimpire라든가. 그러면 실제 개발 작업은 다 bash 창 열어서 하고 파일 관리는 그냥 윈도 익스플로러로 하고 브라우저는 윈도 크롬을 쓸 수 있다. bash 창에 탭이 없어서 보조 도구를 써야 한다거나 하는 사소한 단점이 있지만, 꽤나 완벽에 가까운 방법이다.

하지만 난 그런 타입 아니다. 나도 Vim이 꽤 손에 익었고, 리눅스 유틸리티들 꽤 쓰는 편이지만, Vim에 온갖 플러그인을 다 갖다붙여도 PyCharm의 생산성에 대항할 수 없다. 신생 언어거나 듣보잡 언어라서 IDE가 미비한 경우라면 모를까, 자바, 파이썬, Node.js 같은 메이저 언어를 사용한다면 Vim은 현명한 선택이 아니다. IDE를 쓰는 사람들에게는 역시 IDE에서 WSL을 사용할 수 있어야 한다. 내 경우는 주력 언어가 파이썬이니까 WSL 파이썬을 PyCharm에서 세팅할 수 있어야 한다. 그러나, 윈도우 개발환경 삽질기에서 보듯, 아직은 그게 안된다. 여러 가지 꼼수들을 동원하면 되는 방법이 있을 듯 싶지만, 삽질이 적지 않을 것이다. 사실 원리를 생각하면 완벽한 호환을 기대하기 어려울 수 있다. 처음에는 그냥 `python 파라미터`와 같이 실행하던 걸 `wsl python 파라미터`로 실행하면 되는 게 아닐까 싶었는데, 그렇지 않았다. 파라미터 자체가 윈도와 리눅스가 다르기 때문이다. 일단 파일 경로의 기준이 다르고 표현도 다르기 때문에 변환이 필요한데, 이 변환이 늘 정확하게 되진 않고 약간의 예외들이 존재한다. 그래서 이 방안은 일단 접었다.

vcxsrv로 X 서버를 띄우고 bash 창에서 GUI 프로그램 실행하기

WSL은 디바이스에 직접 엑세스할 수 없기 때문에 X 서버를 직접 띄울 수 없다. 하지만 클라이언트 - 서버 구조라는 X의 특성상, 윈도우용 X 서버를 띄우고 WSL에서 띄운 GUI 프로그램을 윈도우용 X 서버에 디스플레이하는 것이 가능하다. 이론적으로 된다는 건 당연히 알고 있었지만, 막상 이게 동작하는 걸 보니 신기한 기분이 들었다. 프로토콜을 맞추면 전혀 다른 것들이 맞물려 돌아가곤 한다는 것은 소프트웨어의 매력 중 하나다. 그래서 그놈 터미널을 띄우니까 잘 동작했다. 그놈 터미널이 뜨는 걸 보니 윈도우 네이티브로 개발할 때도 이걸 메인 터미널로 쓰고 싶다는 생각이 순간 들었다. 하지만 이것도 WSL 위에서 도는 것인지라 별 도움은 안된다. 노틸러스는 처음에 에러가 났지만 에러 메시지를 보고 대충 땜빵하니까 떴다. 이런 식이면 PyCharm도 뜨지 않을까? 정말로 리눅스용 PyCharm도 떴고, 잘 동작했다. 약간 느린 감은 있지만, 충분히 참을 만한 수준이다. 한글 폰트가 부분적으로 깨지는데, 이것도 손볼 수 있을 것 같다.

여기까지만 해도 WSL 안에서 그놈 터미널로 커맨드라인이 필요한 일들을 하고, PyCharm으로 개발을 하는 그림이 가능해진다. 굿.

그러나, 막상 이렇게 해보니까 사용성에서 조금씩 불편함이 나왔다. GUI 프로그램을 항상 bash 창에서만 실행한다는 게 많이 불편했다.